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IPv6 Node Requirements 

Status of This Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 
Copyright (C) The Internet Society (2006). 

Abstract 
This document defines requirements for IPv6 nodes. It is expected 
that IPv6 will be deployed in a wide range of devices and situations. 
Specifying the requirements for IPv6 nodes allows IPv6 to function 
well and interoperate in a large number of situations and 


deployments. 
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1. Introduction 


The goal of this document is to define the common functionality 
required from both IPv6 hosts and routers. Many IPv6 nodes will 
implement optional or additional features, but this document 
summarizes requirements from other published Standards Track 
documents in one place. 


This document tries to avoid discussion of protocol details, and 
references RFCs for this purpose. This document is informational in 
nature and does not update Standards Track RFCs. 


Although the document points to different specifications, it should 
be noted that in most cases, the granularity of requirements are 
smaller than a single specification, as many specifications define 
multiple, independent pieces, some of which may not be mandatory. 


As it is not always possible for an implementer to know the exact 
usage of IPv6 in a node, an overriding requirement for IPv6 nodes is 
that they should adhere to Jon Postel’s Robustness Principle: 


Be conservative in what you do, be liberal in what you accept from 
others [RFC-793]. 
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1.1. Requirement Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC-2119]. 


1.2. Scope of This Document 
IPv6 covers many specifications. It is intended that IPv6 will be 
deployed in many different situations and environments. Therefore, 
it is important to develop the requirements for IPv6 nodes to ensure 
interoperability. 


This document assumes that all IPv6 nodes meet the minimum 
requirements specified here. 


1.3. Description of IPv6é Nodes 


From the Internet Protocol, Version 6 (IPv6) Specification 
[RFC-2460], we have the following definitions: 


Description of an IPv6 Node 
- a device that implements IPv6. 
Description of an IPv6 router 


- anode that forwards IPv6 packets not explicitly addressed 
to itself. 


Description of an IPv6é Host 
- any node that is not a router. 
2. Abbreviations Used in This Document 
ATM Asynchronous Transfer Mode 
AH Authentication Header 
DAD Duplicate Address Detection 
ESP Encapsulating Security Payload 
ICMP Internet Control Message Protocol 


IKE Internet Key Exchange 
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MIB Management Information Base 
MLD Multicast Listener Discovery 
MTU Maximum Transfer Unit 

NA Neighbor Advertisement 

NBMA Non-Broadcast Multiple Access 
ND Neighbor Discovery 


NS Neighbor Solicitation 


NUD Neighbor Unreachability Detection 
PPP Point-to-Point Protocol 
PVC Permanent Virtual Circuit 
SVC Switched Virtual Circuit 

3. Sub-IP Layer 
An IPv6é node must include support for one or more IPv6 link-layer 
specifications. Which link-layer specifications are included will 
depend upon what link-layers are supported by the hardware available 
on the system. It is possible for a conformant IPv6 node to support 
IPv6 on some of its interfaces and not on others. 
As IPv6 is run over new layer 2 technologies, it is expected that new 
specifications will be issued. This section highlights some major 
layer 2 technologies and is not intended to be complete. 


3.1. Transmission of IPv6 Packets over Ethernet Networks - RFC 2464 


Nodes supporting IPv6 over Ethernet interfaces MUST implement 
Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. 


3.2. IP version 6 over PPP - RFC 2472 


Nodes supporting IPv6 over PPP MUST implement IPv6 over PPP 
[RFC-2472]. 


3.3. IPv6 over ATM Networks - RFC 2492 


Nodes supporting IPv6é over ATM Networks MUST implement IPv6 over ATM 
Networks [RFC-2492]. Additionally, RFC 2492 states: 
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4.1. 


4.2. 


A minimally conforming IPv6/ATM driver SHALL support the PVC mode 
of operation. An IPv6/ATM driver that supports the full SVC mode 
SHALL also support PVC mode of operation. 


IP Layer 
Internet Protocol Version 6 - RFC 2460 


The Internet Protocol Version 6 is specified in [RFC-2460]. This 
specification MUST be supported. 


Unrecognized options in Hop-by-Hop Options or Destination Options 
extensions MUST be processed as described in RFC 2460. 


The node MUST follow the packet transmission rules in RFC 2460. 


Nodes MUST always be able to send, receive, and process fragment 
headers. All conformant IPv6 implementations MUST be capable of 
sending and receiving IPv6 packets; the forwarding functionality MAY 
be supported. 


RFC 2460 specifies extension headers and the processing for these 
headers. 


A full implementation of IPv6 includes implementation of the 
following extension headers: Hop-by-Hop Options, Routing (Type 0), 
Fragment, Destination Options, Authentication and Encapsulating 
Security Payload [RFC-2460]. 


An IPv6 node MUST be able to process these headers. It should be 
noted that there is some discussion about the use of Routing Headers 
and possible security threats [IPv6-RH] that they cause. 


Neighbor Discovery for IPv6 - RFC 2461 
Neighbor Discovery SHOULD be supported. [RFC-2461] states: 


"Unless specified otherwise (in a document that covers operating 
IP over a particular link type) this document applies to all link 
types. However, because ND uses link-layer multicast for some of 
its services, it is possible that on some link types (e.g., NBMA 
links) alternative protocols or mechanisms to implement those 
services will be specified (in the appropriate document covering 
the operation of IP over a particular link type). The services 
described in this document that are not directly dependent on 
multicast, such as Redirects, Next-hop determination, Neighbor 
Unreachability Detection, etc., are expected to be provided as 
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specified in this document. The details of how one uses ND on 
NBMA links is an area for further study." 


Some detailed analysis of Neighbor Discovery follows: 


Router Discovery is how hosts locate routers that reside on an 
attached link. Router Discovery MUST be supported for 
implementations. 


Prefix Discovery is how hosts discover the set of address prefixes 
that define which destinations are on-link for an attached link. 
Prefix discovery MUST be supported for implementations. Neighbor 
Unreachability Detection (NUD) MUST be supported for all paths 
between hosts and neighboring nodes. It is not required for paths 
between routers. However, when a node receives a unicast Neighbor 
Solicitation (NS) message (that may be a NUD’s NS), the node MUST 
respond to it (i.e., send a unicast Neighbor Advertisement). 


Duplicate Address Detection MUST be supported on all links supporting 
link-layer multicast (RFC 2462, Section 5.4, specifies DAD MUST take 
place on all unicast addresses). 

A host implementation MUST support sending Router Solicitations. 
Receiving and processing Router Advertisements MUST be supported for 
host implementations. The ability to understand specific Router 
Advertisement options is dependent on supporting the specification 
where the RA is specified. 

Sending and Receiving Neighbor Solicitation (NS) and Neighbor 
Advertisement (NA) MUST be supported. NS and NA messages are 
required for Duplicate Address Detection (DAD). 


Redirect functionality SHOULD be supported. If the node is a router, 
Redirect functionality MUST be supported. 


4.3. Path MTU Discovery and Packet Size 

4.3.1. Path MTU Discovery - RFC 1981 
Path MTU Discovery [RFC-1981] SHOULD be supported, though minimal 
implementations MAY choose to not support it and avoid large packets. 
The rules in RFC 2460 MUST be followed for packet fragmentation and 
reassembly. 


4.3.2. IPv6é Jumbograms - RFC 2675 


IPv6 Jumbograms [RFC-2675] MAY be supported. 
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4. 


4. 


4. 


4 


4. ICMP for the Internet Protocol Version 6 (IPv6) - RFC 2463 


ICMPv6 [RFC-2463] MUST be supported. 


.5. Addressing 


.5.1. IP Version 6 Addressing Architecture - RFC 3513 


The IPv6 Addressing Architecture [RFC-3513] MUST be supported as 
updated by [RFC-3879]. 


5.2. IPv6 Stateless Address Autoconfiguration - RFC 2462 


IPv6 Stateless Address Autoconfiguration is defined in [RFC-2462]. 
This specification MUST be supported for nodes that are hosts. 
Static address can be supported as well. 


Nodes that are routers MUST be able to generate link local addresses 
as described in RFC 2462 [RFC-2462]. 


From 2462: 


The autoconfiguration process specified in this document applies 
only to hosts and not routers. Since host autoconfiguration uses 
information advertised by routers, routers will need to be 
configured by some other means. However, it is expected that 
routers will generate link-local addresses using the mechanism 
described in this document. In addition, routers are expected to 
successfully pass the Duplicate Address Detection procedure 
described in this document on all addresses prior to assigning 
them to an interface. 


Duplicate Address Detection (DAD) MUST be supported. 


5.3. Privacy Extensions for Address Configuration in IPv6 - RFC 3041 


Privacy Extensions for Stateless Address Autoconfiguration [RFC-3041] 
SHOULD be supported. It is recommended that this behavior be 
configurable on a connection basis within each application when 
available. It is noted that a number of applications do not work 
with addresses generated with this method, while other applications 
work quite well with them. 


-5.4. Default Address Selection for IPv6 - RFC 3484 


The rules specified in the Default Address Selection for IPv6 
[RFC-3484] document MUST be implemented. It is expected that IPv6 
nodes will need to deal with multiple addresses. 
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4. 


De 


5; 


z6: 


5. Stateful Address Autoconfiguration 


Stateful Address Autoconfiguration MAY be supported. DHCPv6 
[RFC-3315] is the standard stateful address configuration protocol; 
see Section 5.3 for DHCPv6 support. 


Nodes which do not support Stateful Address Autoconfiguration may be 
unable to obtain any IPv6 addresses, aside from link-local addresses, 
when it receives a router advertisement with the ’M’ flag (Managed 
address configuration) set and that contains no prefixes advertised 
for Stateless Address Autoconfiguration (see Section 4.5.2). 
Additionally, such nodes will be unable to obtain other configuration 
information, such as the addresses of DNS servers when it is 
connected to a link over which the node receives a router 
advertisement in which the ’0’ flag ("Other stateful configuration") 
is set. 


Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 


Nodes that need to join multicast groups SHOULD implement MLDv2 
[RFC-3810]. However, if the node has applications that only need 
support for Any-Source Multicast [RFC-3569], the node MAY implement 
MLDvl [RFC-2710] instead. If the node has applications that need 
support for Source-Specific Multicast [RFC-3569, SSM-ARCH], the node 
MUST support MLDv2 [RFC-3810]. 


When MLD is used, the rules in the "Source Address Selection for the 
Multicast Listener Discovery (MLD) Protocol" [RFC-3590] MUST be 
followed. 


DNS and DHCP 


.1. DNS 


DNS is described in [RFC-1034], [RFC-1035], [RFC-3152], [RFC-3363], 
and [RFC-3596]. Not all nodes will need to resolve names; those that 
will never need to resolve DNS names do not need to implement 
resolver functionality. However, the ability to resolve names is a 
basic infrastructure capability that applications rely on and 
generally needs to be supported. All nodes that need to resolve 
names SHOULD implement stub-resolver [RFC-1034] functionality, as in 
RFC 1034, Section 5.3.1, with support for: 


- AAAA type Resource Records [RFC-3596]; 


- reverse addressing in ip6.arpa using PTR records [RFC-3152]; 
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- EDNSO [RFC-2671] to allow for DNS packet sizes larger than 512 
octets. 


Those nodes are RECOMMENDED to support DNS security extensions 
[RFC-4033], [RFC-4034], and [RFC-4035]. 


Those nodes are NOT RECOMMENDED to support the experimental A6 and 
DNAME Resource Records [RFC-3363]. 


5.2. Dynamic Host Configuration Protocol for IPv6é (DHCPv6) - RFC 3315 
5.2.1. Managed Address Configuration 


The method by which IPv6 nodes that use DHCP for address assignment 
can obtain IPv6 addresses and other configuration information upon 
receipt of a Router Advertisement with the ’M’ flag set is described 
in Section 5.5.3 of RFC 2462. 


In addition, in the absence of a router, those IPv6 nodes that use 
DHCP for address assignment MUST initiate DHCP to obtain IPv6 
addresses and other configuration information, as described in 
Section 5.5.2 of RFC 2462. Those IPv6 nodes that do not use DHCP for 
address assignment can ignore the ’M’ flag in Router Advertisements. 


5.2.2. Other Configuration Information 


The method by which IPv6 nodes that use DHCP to obtain other 
configuration information can obtain other configuration information 
upon receipt of a Router Advertisement with the ’0O’ flag set is 
described in Section 5.5.3 of RFC 2462. 


Those IPv6 nodes that use DHCP to obtain other configuration 
information initiate DHCP for other configuration information upon 
receipt of a Router Advertisement with the ’0O’ flag set, as described 
in Section 5.5.3 of RFC 2462. Those IPv6é nodes that do not use DHCP 
for other configuration information can ignore the ’0’ flag in Router 
Advertisements. 


An IPv6 node can use the subset of DHCP (described in [RFC-3736]) to 
obtain other configuration information. 


5.3.3. Use of Router Advertisements in Managed Environments 
Nodes using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 


are expected to determine their default router information and on- 
link prefix information from received Router Advertisements. 
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6. IPv4 Support and Transition 
IPv6 nodes MAY support IPv4. 
6.1. Transition Mechanisms 
6.1.1. Transition Mechanisms for IPv6 Hosts and Routers - RFC 2893 


If an IPv6 node implements dual stack and tunneling, then [RFC-4213] 
MUST be supported. 


7. Mobile IP 


The Mobile IPv6 [RFC-3775] specification defines requirements for the 
following types of nodes: 


mobile nodes 
- correspondent nodes with support for route optimization 


- home agents 


all IPv6é routers 
Hosts MAY support mobile node functionality described in Section 8.5 
of [RFC-3775], including support of generic packet tunneling [RFC- 


2473] and secure home agent communications [RFC-3776]. 


Hosts SHOULD support route optimization requirements for 
correspondent nodes described in Section 8.2 of [RFC-3775]. 


Routers SHOULD support the generic mobility-related requirements for 
all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY 
support the home agent functionality described in Section 8.4 of 
[RFC-3775], including support of [RFC-2473] and [RFC-3776]. 

8. Security 
This section describes the specification of IPsec for the IPv6 node. 


8.1. Basic Architecture 


Security Architecture for the Internet Protocol [RFC-4301] MUST be 
supported. 
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8.2. Security Protocols 
ESP [RFC-4303] MUST be supported. AH [RFC-4302] MUST be supported. 
8.3. Transforms and Algorithms 


Current IPsec RFCs specify the support of transforms and algorithms 
for use with AH and ESP: NULL encryption, DES-CBC, HMAC-SHA-1-96, and 
HMAC-MD5-96. However, "Cryptographic Algorithm Implementation 
Requirements For ESP And AH" [RFC-4305] contains the current set of 
mandatory to implement algorithms for ESP and AH. It also specifies 
algorithms that should be implemented because they are likely to be 
promoted to mandatory at some future time. IPv6é nodes SHOULD conform 
to the requirements in [RFC-4305], as well as the requirements 
specified below. 


Since ESP encryption and authentication are both optional, support 
for the NULL encryption algorithm [RFC-2410] and the NULL 
authentication algorithm [RFC-4303] MUST be provided to maintain 
consistency with the way these services are negotiated. However, 
while authentication and encryption can each be NULL, they MUST NOT 
both be NULL. The NULL encryption algorithm is also useful for 
debugging. 


The DES-CBC encryption algorithm [RFC-2405] SHOULD NOT be supported 
within ESP. Security issues related to the use of DES are discussed 
in [DESDIFF], [DESINT], and [DESCRACK]. DES-CBC is still listed as 
required by the existing IPsec RFCs, but updates to these RFCs will 
be published in the near future. DES provides 56 bits of protection, 
which is no longer considered sufficient. 


The use of the HMAC-SHA-1-96 algorithm [RFC-2404] within AH and ESP 
MUST be supported. The use of the HMAC-MD5-96 algorithm [RFC-2403] 
within AH and ESP MAY also be supported. 


The 3DES-CBC encryption algorithm [RFC-2451] does not suffer from the 
same security issues as DES-CBC, and the 3DES-CBC algorithm within 
ESP MUST be supported to ensure interoperability. 


The AES-128-CBC algorithm [RFC-3602] MUST also be supported within 
ESP. AES-128 is expected to be a widely available, secure, and 
efficient algorithm. While AES-128-CBC is not required by the 
current IPsec RFCs, it is expected to become required in the future. 
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8.4. Key Management Methods 


An implementation MUST support the manual configuration of the 
security key and SPI. The SPI configuration is needed in order to 
delineate between multiple keys. 


Key management SHOULD be supported. Examples of key management 
systems include IKEv2 [RFC-4306] and Kerberos; S/MIME and TLS include 
key management functions. 


Where key refresh, anti-replay features of AH and ESP, or on-demand 
creation of Security Associations (SAs) is required, automated keying 
MUST be supported. 


Key management methods for multicast traffic are also being worked on 
by the MSEC WG. 


9. Router-Specific Functionality 
This section defines general host considerations for IPv6é nodes that 
act as routers. Currently, this section does not discuss routing- 
specific requirements. 

9.1. General 

9.1.1. IPv6 Router Alert Option - RFC 2711 
The IPv6 Router Alert Option [RFC-2711] is an optional IPv6 Hop-by- 
Hop Header that is used in conjunction with some protocols (e.g., 
RSVP [RFC-2205] or MLD [RFC-2710]). The Router Alert option will 
need to be implemented whenever protocols that mandate its usage are 


implemented. See Section 4.6. 


9.1.2. Neighbor Discovery for IPv6é - RFC 2461 


Sending Router Advertisements and processing Router Solicitation MUST 
be supported. 


10. Network Management 
Network Management MAY be supported by IPv6 nodes. However, for IPv6 
nodes that are embedded devices, network management may be the only 
possible way of controlling these nodes. 


10.1. Management Information Base Modules (MIBs) 


The following two MIBs SHOULD be supported by nodes that support an 
SNMP agent. 
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10. 


10. 


das. 


22. 


12s 


1.1. IP Forwarding Table MIB 


IP Forwarding Table MIB [RFC-4292] SHOULD be supported by nodes that 
support an SNMP agent. 


1.2. Management Information Base for the Internet Protocol (IP) 


IP MIB [RFC-4293] SHOULD be supported by nodes that support an SNMP 
agent. 


Security Considerations 
This document does not affect the security of the Internet, but 
implementations of IPv6 are expected to support a minimum set of 
security features to ensure security on the Internet. "IP Security 
Document Roadmap" [RFC-2411] is important for everyone to read. 


The security considerations in RFC 2460 state the following: 


The security features of IPv6 are described in the Security 
Architecture for the Internet Protocol [RFC-2401]. 


RFC 2401 has been obsoleted by RFC 4301, therefore refer RFC 4301 for 
the security features of IPv6. 
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